Universal object delivery and template-based file delivery

ABSTRACT

Data objects can be delivered over a network using a file delivery system and universal object delivery and template-based file delivery. This might be done by forming source data into a sequence of data objects represented by symbols in packets, sending those to receivers on request, wherein a transmitter obtains a template file delivery table with delivery metadata for the data objects, and constructing a first transmission object identifier for a data object based on a transmission object identifier construction rule described in the template file delivery table. A receiver might receive packets, extract a second transmission object identifier, associate encoded symbols comprising the received data packet with the data object if the first transmission object identifier and the second transmission object identifier identify the same data object, and recover, at least approximately, the source data for the data object based on the encoded symbols associated with the data object.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.13/753,442, filed Jan. 29, 2013, which claims the benefit of U.S.Provisional Application No. 61/615,796 entitled “Universal ObjectDelivery and Template-Based FLUTE Delivery,” filed Mar. 26, 2012, theentire contents of which are herein incorporated by reference in theirentireties for all purposes.

FIELD OF THE INVENTION

The present invention relates to encoding and decoding data incommunications systems and more specifically to communication systemsthat encode and decode data to account for errors and gaps incommunicated data in an efficient manner and that handle different filedelivery methods, as well as using existing infrastructures for novelfile delivery processes.

BACKGROUND OF THE INVENTION

Techniques for transmission of files between a sender and a recipientover a communications channel are the subject of much literature.Preferably, a recipient desires to receive an exact copy of datatransmitted over a channel by a sender with some level of certainty.Where the channel does not have perfect fidelity (which covers most allphysically realizable systems), one concern is how to deal with datalost or garbled in transmission. Lost data (erasures) are often easierto deal with than corrupted data (errors) because the recipient cannotalways tell when corrupted data is data received in error. Manyerror-correcting codes have been developed to correct for erasuresand/or for errors. Typically, the particular code used is chosen basedon some information about the infidelities of the channel through whichthe data is being transmitted and the nature of the data beingtransmitted. For example, where the channel is known to have longperiods of infidelity, a burst error code might be best suited for thatapplication. Where only short, infrequent errors are expected a simpleparity code might be best.

As used herein, “source data” refers to data that is available at one ormore senders and that a receiver is used to obtain, by recovery from atransmitted sequence with or without errors and/or erasures, etc. Asused herein, “encoded data” refers to data that is conveyed and can beused to recover or obtain the source data. In a simple case, the encodeddata is a copy of the source data, but if the received encoded datadiffers (due to errors and/or erasures) from the transmitted encodeddata, in this simple case the source data might not be entirelyrecoverable absent additional data about the source data. Transmissioncan be through space or time. In a more complex case, the encoded datais generated based on source data in a transformation and is transmittedfrom one or more senders to receivers. The encoding is said to be“systematic” if the source data is found to be part of the encoded data.In a simple example of systematic encoding, redundant information aboutthe source data is appended to the end of the source data to form theencoded data.

Also as used herein, “input data” refers to data that is present at aninput of an FEC (forward-error correcting) encoder apparatus or an FECencoder module, component, step, etc., (“FEC encoder”) and “output data”refers to data that is present at an output of an FEC encoder.Correspondingly, output data would be expected to be present at an inputof an FEC decoder and the FEC decoder would be expected to output theinput data, or a correspondence thereof, based on the output data itprocessed. In some cases, the input data is, or includes, the sourcedata, and in some cases, the output data is, or includes, the encodeddata. For example, the input data would be the source data if there isno processing before the input of an FEC encoder. However, in somecases, the source data is processed into a different form (e.g., astatic encoder, an inverse encoder or another process) to generateintermediate data that is presented to the FEC encoder instead of thesource data.

In some cases, a sender device or sender program code may comprise morethan one FEC encoder, i.e., source data is transformed into encoded datain a series of a plurality of FEC encoders. Similarly at the receiver,there may be more than one FEC decoder applied to generate source datafrom received encoded data.

Data can be thought of as partitioned into symbols. An encoder is acomputer system, device, electronic circuit, or the like, that generatesencoded symbols or output symbols from a sequence of source symbols orinput symbols and a decoder is the counterpart that recovers a sequenceof source symbols or input symbols from received or recovered encodedsymbols or output symbols. The encoder and decoder are separated in timeand/or space by the channel and any received encoded symbols might notbe exactly the same as corresponding transmitted encoded symbols andthey might not be received in exactly the same sequence as they weretransmitted. The “size” of a symbol can be measured in bits, whether ornot the symbol is actually broken into a bit stream, where a symbol hasa size of M bits when the symbol is selected from an alphabet of 2^(M)symbols. In many of the examples herein, symbols are measured in octetsand codes might be over a field of 256 possibilities (there are 256possible 8-bit patterns within each octet), but it should be understoodthat different units of data measurement can be used and it iswell-known to measure data in various ways. In the general literature,the term “byte” is sometimes used interchangeably with the term “octet”to indicate an 8-bit value, although in some contexts “byte” indicatesan X-bit value where X is not equal to 8, e.g., X=7, and thus, ingeneral, the term “octet” is used herein. Unless otherwise indicated,the examples herein are not limited to a particular integer ornon-integer number of bits per symbol.

FIG. 1 shows the general work flow associated with coding and decodingand the terminology used to describe the block structure of a sourceblock, symbols, sub-blocks, etc. Symbols may be either source symbols(i.e., copies of the blocks constituting the original object) or repairsymbols (i.e., data produced by the coding process that can be used torepair erasures in the source blocks). Parameters critical to theoperation of the coding system might be contained within a structurecalled the Object Transmission Information (“OTI”). The OTI for acollection of related symbols may be communicated one or more timesbetween sender(s) and receiver(s). When symbols are placed into messagesfor delivery via a channel (e.g., a network packet over a network),bookkeeping information is sometimes added to the symbols. Thisinformation is placed within the Payload Identifier (FEC Payload ID). Inseveral particular examples, the Payload ID contains a source blocknumber (“SBN”) and a unique encoding symbol identifier (“ESI”). ThePayload ID (and OTI) can contain different information for differenttypes of codes and use cases.

Forward Error Correction (“FEC”) Object Transmission Information(“OTI”), or “FEC OTI”

Based on the FEC OTI a receiver receives (or is able to infer), thereceiver can determine the source block and sub-block structure of thefile transfer. In [Raptor-RFC-5053] and [IETF-RFC-6330], the FEC PayloadID contains the pair (SBN, ESI), where in [Raptor-RFC-5053] SBN is 16bits and the ESI is 16 bits, whereas in [IETF-RFC-6330] the SBN is 8bits and the ESI is 24 bits, as illustrated in FIG. 2 herein. Onedisadvantage of this format is that one has to pre-determine the numberof bits to allocate to the SBN and to the ESI, and it is sometimesdifficult to determine a proper mix that will be adequate for all filedelivery parameters.

For example, when using [Raptor-RFC-5053] with 16-bit ESIs, having only2¹⁶=65,536 ESI values available might be limiting in some situations.For example, with a source block containing 8,192 source symbols, thenumber of encoded symbols can only be a factor of 8 larger (i.e.,because 8192*8=65536), limiting the possible code rate that could beused to below ⅛ in this case. In this example, using 16 bits to hold theSBN (providing for up to 2¹⁶=65,536 source blocks) could be more thanwould ever be used. More concretely, with 8,192 source symbols of 1,024octets each, the size of the file that could be supported is 524 GB,which in many applications is orders of magnitude larger than is needed.

As another example, when using [IETF-RFC-6330], having only 2⁸=256 SBNsavailable might be limiting in some situations. For a 4 GB file, if eachsource block is limited to 8 MB (which might be the case if the maximumsub-block size is 256 KB, the minimum sub-symbol size is 32 octets, andthe symbol size is 1,024 octets) then limiting the number of sourceblocks to 256 limits the file size to 2 GB. In this example, it may bethat having 2²⁴=16,777,216 possible encoded symbols (ESIs) are more thanwould ever be used, e.g., with 8,192 source symbols the number ofpossible encoded symbols is 2,048 times larger, which may never beneeded in some applications.

Erasure code processing as described above can be used in conjunctionwith a variety of content delivery systems and protocols. In some cases,specialized servers are required, which can be more expensive toimplement, support and maintain that using more common, conventionalInternet servers to support content delivery. Therefore, it is desirableto have methods for delivering content and repair symbols that are lesscomplex to implement.

In some cases, it is preferable to use more efficient signaling methods.One such method, designed for use with uni-directional communicationchannels and multicast communication is known as FLUTE [FLUTE]. FLUTEaugments the basic capabilities of the erasure coding techniques withmethods to deliver file and directory information (e.g., file names tobe associated with streams of symbols). A receiver that implements bothFLUTE and the appropriate set of erasure codes is able to identify thenames and contents of file objects. FLUTE can, in turn, be carriedwithin (or on “top” of) a variety of transfer mechanisms such as UDP/IP(e.g., in the Internet). In the context of MBMS and eMBMS, where the3GPP standards defining organization sets standards, FLUTE has beenselected for delivery of streaming content. In particular, the stream isdelivered as a sequence of DASH formatted files. However, the signalingwithin FLUTE is not specifically designed for delivering sequence ofrelated files. Thus, improved methods for signaling and deliveringsequences of files within the FLUTE architecture is needed.

REFERENCES

Each of the references below is herein incorporated by reference intheir entirety for all purposes:

-   [3GP-DASH] “Transparent end-to-end Packet-switched Streaming Service    (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP    (3GP-DASH)”, 3GPP specification TS 26.247, Rel. 10, Jun. 8, 2011.-   [FEC BB] Watson, M., Luby, M., and L. Vicisano, “Forward Error    Correction (FEC) Building Block”, IETF RFC 5052 (August 2007);-   [FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., Lehtonen, R.,    “FLUTE—File Delivery over Unidirectional Transport”, IETF RFC 6726    (November 2012);-   [IANA-FEC] http://www.iana.org/assignments/rmt-fec-parameters-   [IETF-RFC-6330] M. Luby, A. Shokrollahi, M. Watson, T.    Stockhammer, L. Minder, “RaptorQ Forward Error Correction Scheme for    Object Delivery”, IETF RFC 6330 (August, 2011);-   [LCT] Luby, M., Watson, M., Vicisano, L., “Layered Coding Transport    (LCT) Building Block”, IETF RFC 5651 (October 2009)-   [Luby2010] U.S. patent application Ser. No. 12/887,492 naming Mark    Watson, et al. and entitled “Enhanced Block-Request Streaming Using    URL Templates and Construction Rules”, filed Sep. 21, 2010.-   [Luby2011] U.S. Patent Publication 2012/0099593 naming Michael Luby    and entitled “Universal File Delivery Methods for Providing Unequal    Error Protection and Bundled File Delivery Services”, filed Mar. 4,    2011, published Apr. 26, 2012.-   [Luby2012] U.S. patent application Ser. No. 13/545,697 naming    Michael Luby and entitled “Switch Signaling Methods Providing    Improved Switching between Representations for Adaptive HTTP    Streaming”, filed Jul. 10, 2012.-   [MBMS] “Multimedia Broadcast/Multicast Service (MBMS); Protocols and    codecs”, 3GPP specification TS 26.346, Rel. 10, version 10.5.0, Sep.    21, 2012.-   [MPEG-DASH] “Information technology—Dynamic adaptive streaming over    HTTP (DASH)—Part 1: Media presentation description and segment    formats”, ISO/IEC 23009-1, First edition Apr. 1, 2012.-   [Raptor-RFC-5053] M. Luby, A. Shokrollahi, M. Watson, T.    Stockhammer, “Raptor Forward Error Correction Scheme for Object    Delivery”, IETF RFC 5053 (September 2007).-   [RFC 4566] M. Handley, V. Jacobson, C. Perkins, “SDP: Session    Description Protocol”, IETF RFC 4566, July 2006.

SUMMARY OF THE INVENTION

In embodiments of a file delivery method and apparatus, sequences ofrelated files using template based methods are signaled and delivered.Thus, improved methods of signaling and delivering DASH streams of filesusing the FLUTE protocol are provided.

The following detailed description together with the accompanyingdrawings will provide a better understanding of the nature andadvantages of the present invention.

Various elements might be implemented using computer readable media forexecution by a processor for controlling data downloading over a networkpath between a source and a receiver coupled by the network path. Otheraspects of the invention should be apparent from this description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating the general work flow associated withcoding and decoding and the terminology used to describe the blockstructure of a source block, symbols, sub-blocks, etc.

FIG. 2A is a diagram illustrating a conventional FEC Payload ID thatillustrates an FEC Payload ID for a payload as might be used with[Raptor-RFC-5053], while FIG. 2B is a diagram illustrating aconventional FEC Payload ID that illustrates an FEC Payload ID for apayload as might be used with [IETF-RFC-6330].

FIG. 3 depicts elements of a block request streaming system according toembodiments of the present invention.

FIG. 4 illustrates the block request streaming system of FIG. 3, showinggreater detail in the elements of a client system that is coupled to ablock serving infrastructure (“BSI”) to receive data that is processedby a content ingestion system.

FIG. 5 is a diagram illustrating the possible arrangement of anapplication and a proxy system that is able to deliver data to anapplication. The particular example depicted is a media playbackapplication using a manifest file that consumes multiple segments (i.e.,files containing multimedia information or samples).

FIG. 6 illustrates a hardware/software implementation of an ingestionsystem.

FIG. 7 illustrates a hardware/software implementation of a clientsystem.

FIG. 8 illustrates possible structures of the content store shown inFIG. 3, including segments and media presentation descriptor (“MPD”)files, and a breakdown of segments, timing, and other structure withinan MPD file.

FIG. 9 is a diagram illustrating the FEC Payload ID for a basicuniversal file delivery (“UFD”) method.

FIG. 10 is a flow chart that illustrates a sender basic UFD method.

FIG. 11 is a flow chart that illustrates a receiver basic UFD method.

FIG. 12 is a diagram illustrating some aspects of the overallFLUTE/ALC/LCT/FEC building block protocols.

FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI).

FIG. 14 illustrates an example object with FEC Payload ID (UOSI).

In the figures, like items are referenced with like numbers andsub-indices are provided in parentheses to indicate multiple instancesof like or identical items. Unless otherwise indicated, the finalsub-index (e.g., “N” or “M”) is not intended to be limiting to anyparticular value and the number of instances of one item can differ fromthe number of instances of another item even when the same number areillustrated and the sub-index is reused.

DETAILED DESCRIPTION OF THE INVENTION

In embodiments herein, file delivery is performed by anencoder/transmitter system that sends a file and a receiver/decodersystem that receives a file. The format of the transmissions iscoordinated so that the decoder understands what the encoder encoded. Asshown in various examples below, file delivery is an example of generalobject delivery and unless otherwise indicated, it should be apparentfrom these examples that objects can be treated as files and possiblyvice versa.

In a packet delivery system, the data is organized into packets andtransmitted as packets. Each packet has elements that allow a receiverto determine what is in the packet and how it is laid out. Using thetechniques described herein, flexibility is provided for transmittingpackets where forward error correction (“FEC”) is used.

Using these techniques, unequal FEC protection can be provided, as wellas bundled delivery of files. “Unequal FEC protection” means thatdifferent portions of files, or different files, are FEC-protected todifferent degrees for the purpose of delivery of those files to devicesover networks susceptible to packet loss. “Bundled delivery of files”means that FEC-protection is applied over multiple files or portions offiles for the purpose of delivery of those files to one or more devicesover networks susceptible to packet loss. It is well-known that whenmany files are delivered as separate files, the resiliency of thedeliveries to packet loss can be much less than if all the files areconcatenated together into a larger file and the larger file isprotected in the delivery. However, a signaling of the structure of thelarger file as a combination of smaller files is required, and thereceiver generally needs to recover the entire large file to recover anyof the smaller files within the large file, even if the receiver is onlyinterested in recovering a subset of the smaller files.

Thus, a preferred file delivery system or method should allow anyflexible combination of the number of source blocks and the number ofencoding symbols per source block that is used as the file deliverystructure for a file. It should also be the case that file deliverymethods provide efficient protection against packet loss, and supportdelivery of the file with different parts of the file protected atdifferent priorities (i.e., with different codes or code rates), whereineach part of the file may have a different source block structure andsub-block structure than other parts of the file. Again, files are insome cases considered specific examples of objects, but herein it shouldbe understood that the examples used herein to describe transport andhandling of files can also be used for data objects that are perhaps notreferred to as files, such as large chunks of data from a database, aportion of a video sequence, etc.

The file/object delivery system or method should provide for thedelivery of many smaller files/objects with the protection efficiency ofa large file/object, simple signaling of the smaller file/objectstructures, and the capabilities for the receiver to independentlyrecover only a subset of the smaller files/objects without recoveringall of the smaller files/objects.

A file delivery system might comprise a broadcast portion and a unicastportion. For readability, “broadcast” might be read to mean “broadcast,multicast, and/or other mechanisms for serving common data to aplurality of users.” “Unicast” refers to movement of data from onesource to one destination, although one logical source might comprisemultiple components and one logical destination might comprise multiplecomponents. In a unicast configuration, typically there is a sourceserver and a destination client, with the source server waiting forrequests from clients and responding to a received request by sendingthe requested data (if otherwise permitted) to the requesting clientspecifically. As is well-known in the art, unicast delivery to a largenumber of destinations can create more scalability challenges thanbroadcast delivery to those same large number of destinations.

Examples of systems with these desirable qualities will now bedescribed.

Apparatus for Sending and Receiving Media Data

One embodiment of the invention is described with reference to FIG. 3,which shows a simplified diagram of a block-request streaming systemembodying the invention.

In FIG. 3, a block-streaming system 100 is illustrated, comprising blockserving infrastructure (“BSI”) 101 in turn comprising an ingestionsystem 103 for ingesting content 102, preparing that content andpackaging it for service by an HTTP streaming server 104 by storing itinto a content store 110 that is accessible to both ingestion system 103and HTTP streaming server 104. As shown, system 100 might also includean HTTP cache 106. In operation, a client 108, such as an HTTP streamingclient, sends requests 112 to HTTP streaming server 104 and receivesresponses 114 from HTTP streaming server 104 or HTTP cache 106. In eachcase, elements shown in FIG. 3 might be implemented, at least in part,in software, therein comprising program code that is executed on aprocessor or other electronics.

The content might comprise movies, audio, 2D planar video, 3D video,other types of video, images, timed text, timed metadata or the like.Some content might involve data that is to be presented or consumed in atimed manner, such as data for presenting auxiliary information (stationidentification, advertising, stock quotes, Flash™ sequences, etc.) alongwith other media being played out. Other hybrid presentations might alsobe used that combine other media and/or go beyond merely audio andvideo.

As illustrated in FIG. 4, media blocks may be stored within a blockserving infrastructure 101(1), which could be, for example, an HTTPserver, a Content Delivery Network device, an HTTP proxy, FTP proxy orserver, or some other media server or system. Block servinginfrastructure 101(1) is connected to a network 122, which could be, forexample, an Internet Protocol (“IP”) network such as the Internet. Ablock-request streaming system client is shown having six functionalcomponents, namely a block selector 123, provided with the metadatadescribed above and performing a function of selecting blocks or partialblocks to be requested from among the plurality of available blocksindicated by the metadata, a block requestor 124, that receives requestinstructions from block selector 123 and performs the operationsnecessary to send a request for the specified block, portions of ablock, or multiple blocks, to block serving infrastructure 101(1) overnetwork 122 and to receive the data comprising the block in return, aswell as a block buffer 125, a buffer monitor 126, a media decoder 127and one or more media transducers 128 that faciliate media consumption.

Block data received by block requestor 124 is passed for temporarystorage to block buffer 125, which stores the media data. Alternatively,the received block data can be stored directly into block buffer 125 asillustrated in FIG. 3. Media decoder 127 is provided with media data byblock buffer 125 and performs such transformations on this data as arenecessary to provide suitable input to media transducers 128, whichrender the media in a form suitable for user or other consumption.Examples of media transducers include visual display devices such asthose found in mobile phones, computer systems or televisions, and mightalso include audio rendering devices, such as speakers or headphones.

An example of a media decoder would be a function that transforms datain the format described in the H.264 video coding standard into analogueor digital representations of video frames, such as a YUV-format pixelmap with associated presentation timestamps for each frame or sample.

Buffer monitor 126 receives information concerning the contents of blockbuffer 125 and, based on this information and possibly otherinformation, provides input to block selector 123, which is used todetermine the selection of blocks to request, as is described herein.

In the terminology used herein, each block has a “playout time” or“duration” that represents the amount of time it would take for thereceiver to play the media included in that block at normal speed. Insome cases, the playout of the media within a block may depend on havingalready received data from previous blocks. In rare cases, the playoutof some of the media in a block may depend on a subsequent block, inwhich case the playout time for the block is defined with respect to themedia that can be played out within the block without reference to thesubsequent block, and the playout time for the subsequent block isincreased by the playout time of the media within this block that canonly playout after having received the subsequent block. Since includingmedia in a block that depends on subsequent blocks is a rare case, inthe remainder of this disclosure we assume that media in one block doesnot depend on subsequent blocks, but note that those skilled in the artwill recognize that this variant can be easily added to the embodimentsdescribed below.

The receiver may have controls such as “pause”, “fast forward”,“reverse”, etc. that may result in the block being consumed by playoutat a different rate, but if the receiver can obtain and decode eachconsecutive sequence of blocks in an aggregate time equal to or lessthan their agreggate playout time excluding the last block in thesequence then the receiver can present the media to the user withoutstalling. In some descriptions herein, a particular position in themedia stream is referred to as a particular “time” in the media,corresponding to the time that would have elapsed between the beginningof the media playout and the time when the particular position in thevideo stream is reached. The time or position in a media stream is aconventional concept. For example, where the video stream comprises 24frames per second, the first frame could be said to have a position ortime of t=0.0 seconds and the 241st frame could be said to have aposition or time of t=10.0 seconds. Naturally, in a frame-based videostream, position or time need not be continuous, as each of the bits inthe stream from the first bit of the 241st frame to just before thefirst bit of the 242nd frame might all have the same time value.

Adopting the above terminology, a block-request streaming system (BRSS)comprises one or more clients that make requests to one or more contentservers (for example, HTTP servers, FTP Servers, etc.). An ingestionsystem comprises one or more ingestion processors, wherein an ingestionprocessor receives content (in real-time or not), processes the contentfor use by the BRSS and stores it into storage accessible to the contentservers, possibly also along with metadata generated by the ingestionprocessor.

The BRSS also might contain content caches that coordinate with thecontent servers. The content servers and content caches might beconventional HTTP servers and HTTP caches that receive requests forfiles or segments in the form of HTTP requests that include a URL, andmay also include a byte range, in order to request less than all of thefile or segment indicated by the URL. The clients might include aconventional HTTP client that makes requests of HTTP servers and handlesthe responses to those requests, where the HTTP client is driven by anovel client system that formulates requests, passes them to the HTTPclient, gets responses from the HTTP client and processes those (orstoring, transforming, etc.) in order to provide them to a presentationplayer for playout by a client device. Typically, the client system doesnot know in advance what media is going to be needed (as the needs mightdepend on user input, changes in user input, etc.), so it is said to bea “streaming” system in that the media is “consumed” as soon as it isreceived, or shortly thereafter. As a result, response delays andbandwidth constraints can cause delays in a presentation, such ascausing a pause in a presentation as the stream catches up to where theuser is in consuming the presentation.

In order to provide for a presentation that is perceived to be of goodquality, a number of details can be implemented in the BRSS, either atthe client end, at the ingestion end, or both. In some cases, thedetails that are implemented are done in consideration of, and to dealwith, the client-server interface at the network. In some embodiments,both the client system and the ingestion system are aware of theenhancement, whereas in other embodiments, only one side is aware of theenhancement. In such cases, the entire system benefits from theenhancement even though one side is not aware of it, while in others,the benefit only accrues if both sides are aware of it but when one sideis not aware, it still operates without failing.

FIG. 5 is a diagram illustrating the possible arrangement of anapplication and a proxy system that is able to deliver data to anapplication. The particular example depicted is a media playbackapplication using a manifest file that consumes multiple segments (i.e.,files containing multimedia information or samples).

As illustrated in FIG. 6, the ingestion system may be implemented as acombination of hardware and software components, according to variousembodiments. The ingestion system may comprise a set of instructionsthat can be executed to cause the system to perform any one or more ofthe methodologies discussed herein. The system may be realized as aspecific machine in the form of a computer. The system may be a servercomputer, a personal computer (PC), or any system capable of executing aset of instructions (sequential or otherwise) that specify actions to betaken by that system. Further, while only a single system isillustrated, the term “system” shall also be taken to include anycollection of systems that individually or jointly execute a set (ormultiple sets) of instructions to perform any one or more of themethodologies discussed herein.

The ingestion system may include the ingestion processor 302 (e.g., acentral processing unit (CPU)), a memory 304 which may store programcode during execution, and disk storage 306, all of which communicatewith each other via a bus 300. The system may further include a videodisplay unit 308 (e.g., a liquid crystal display (LCD) or cathode raytube (CRT)). The system also may include an alphanumeric input device310 (e.g., a keyboard), and a network interface device 312 for receivingcontent source and delivering content store.

The disk storage unit 306 may include a machine-readable medium on whichmay be stored one or more sets of instructions (e.g., software)embodying any one or more of the methodologies or functions describedherein. The instructions may also reside, completely or at leastpartially, within the memory 304 and/or within the ingestion processor302 during execution thereof by the system, with the memory 304 and theingestion processor 302 also constituting machine-readable media.

As illustrated in FIG. 7, the client system may be implemented as acombination of hardware and software components, according to variousembodiments. The client system may comprise a set of instructions thatcan be executed to cause the system to perform any one or more of themethodologies discussed herein. The system may be realized as a specificmachine in the form of a computer. The system may be a server computer,a personal computer (PC), or any system capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that system. Further, while only a single system is illustrated, theterm “system” shall also be taken to include any collection of systemsthat individually or jointly execute a set (or multiple sets) ofinstructions to perform any one or more of the methodologies discussedherein.

The client system may include the client processor 402 (e.g., a centralprocessing unit (CPU)), a memory 404 which may store program code duringexecution, and disk storage 406, all of which communicate with eachother via a bus 400. The system may further include a video display unit408 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)).The system also may include an alphanumeric input device 410 (e.g., akeyboard), and a network interface device 412 for sending requests andreceiving responses.

The disk storage unit 406 may include a machine-readable medium on whichmay be stored one or more sets of instructions (e.g., software)embodying any one or more of the methodologies or functions describedherein. The instructions may also reside, completely or at leastpartially, within the memory 404 and/or within the client processor 402during execution thereof by the system, with the memory 404 and theclient processor 402 also constituting machine-readable media.

Media Presentation Data Model

FIG. 8 illustrates possible structures of the content store shown inFIG. 3, including segments and media presentation description (“MPD”)files, and a breakdown of segments, timing, and other structure withinan MPD file. Details of possible implementations of MPD structures orfiles will now be described. In many examples, the MPD is described as afile, but non-file structures can be used as well.

As illustrated there, content store 110 holds a plurality of sourcesegments 510, MPDs 500 and repair segments 512. An MPD might compriseperiod records 501, which in turn might comprise representation records502, that contain segment information 503 such as references toinitialization segments 504 and media segments 505.

A Basic Universal File Delivery (“UFD”) Method and System

A basic universal file delivery (“UFD”) method and correspondingsystem(s) will now be described, wherein the UFD includes significantadvantages over existing file delivery methods. The Forward ErrorCorrection (“FEC”) Payload ID for the basic UFD method comprises auniversal file symbol identifier (“UFSI”) field, which for example canbe a 32-bit field, as illustrated in FIG. 9. The sender and receivermethods for the basic UFD method will now be described in turn. Again,where files are referred to as objects, “UFSI” might be referred toinstead as “UOSI” (a universal object symbol identifier).

The sender basic UFD method is described with reference to FIG. 10. Thesender can use existing methods to generate the FEC Object TransmissionInformation (“OTI”), for example as described in the [Raptor-RFC-5053]or [IETF-RFC-6330] (see, for example, Section 4.3 of [IETF-RFC-6330]),and use the FEC OTI to determine the source block and sub-blockstructure to be used to transmit the file, and to determine therelationship between (SBN, ESI) pairs and the encoded symbols of thefile (see, for example, Section 4.4 of [IETF-RFC-6330]).

For example, as described in [IETF-RFC-6330], the generated FEC OTI canbe (F, Al, T, Z, N), where F is the size of the file to be transmitted,Al is an alignment factor that is used to make sure that sub-symbols arealigned on memory boundaries that are multiples of Al, T is the size ofthe symbols to be generated and sent in the transmission, Z is thenumber of source blocks into which the file is to be partitioned fortransmission, and N is the number of sub-blocks into which each sourceblock is to partitioned for transmission. This is as shown in Step 800of FIG. 10.

The sender can form encoded symbols to be sent in packets and generatethe SBNs and ESIs for these encoded symbols using existing methods basedon the source block, and if sub-blocking is used, then also thesub-block structure, e.g., as described in [IETF-RFC-6330]. Each time anencoded symbol is to be sent, the sender can determine the SBN A and theESI B for the encoded symbol to be generated, as shown in Step 810 ofFIG. 10, and then the sender can generate the value of the encodedsymbol based on (SBN, ESI)=(A, B) using existing techniques for examplethose described in [IETF-RFC-6330], as shown in Step 820 of FIG. 10.Then, the UFSI C for that encoded symbol is computed as C=B*Z+A, asshown in Step 830 of FIG. 10.

The sender can send the encoded symbol in a packet with the FEC PayloadID of the packet set to the UFSI C of the encoded symbol, as shown inStep 840 of FIG. 10. The sender can then determine if more encodedsymbols are to be sent, as shown in Step 850 of FIG. 10, and if so thenthe sender can generate additional encoded symbols to send, as shown bythe “Yes” branch to Step 810 of FIG. 10 and, and if not then the sendercan finish, as shown by the “No” branch to Step 860 of FIG. 10.

There are many variations of the sender basic UFD method. For example,the sender can send more than one encoded symbol in at least some of thepackets, in which case the FEC Payload ID can be set to the UFSI of thefirst encoded symbol contained in the packet and additional symbolscontained in the packet can be chosen so that their corresponding UFSIvalues are consecutive. For example, if there are three encoded symbolscarried in the packet and the first such symbol has UFSI=4,234, then theother two encoded symbols can be those with UFSIs 4,235 and 4,235,respectively. As examples of other alternatives, the sender maypredetermine how many encoded symbols to generate and determine the(SBN, ESI) values for all the encoded symbols to be generated beforegenerating any of the encoded symbols. As another example, the UFSIvalues may be generated directly without an intermediate step ofgenerating the (SBN, ESI) values.

As another example of a variation, other forms of FEC OTI informationmay be generated. For example, a base UFSI BU may be included in the FECOTI for the file, that can be used as follows: the UFSI to be used bythe FEC sender and receiver for an encoded symbol contained in a packetis U+BU, where U is the UFSI carried in the packet carrying the encodedsymbol. Thus, for example, if a packet carries U=1,045, and the baseUFSI in the FEC OTI is BU=2,000,000, then the encoded symbol UFSI is2,001,045. Usage of the base UFSI has several advantages. For one, theprotocol suite described in [FLUTE], [ALC], [LCT], and/or [FEC BB]associates a Transmission Object Identifier, also called a TOI, with theFEC OTI of a file or object to be transported. It is possible thatencoded symbols for the same file may be sent at different times or indifferent sessions and can be associated with different TOIs. Also, itis advantageous to be able to send encoded packets starting with theUFSI=0 for the packets associated with each different TOI. By having theability to specify a base UFSI as part of the FEC OTI, a different baseUFSI can be associated with each TOI for which encoded symbols are to besent for the file without sending duplicate encoded symbols for thedifferent TOIs. For example, encoded symbols for the same file may besent in packets associated with TOI=1 and associated with TOI=2, whereinthe base UFSI associated with TOI=1 is set to 0, and wherein the baseUFSI associated with TOI=2 is set to 1,000,000. Then, the encodedpackets for both TOI=1 and TOI=2 can contain the sequence of UFSIs 0, 1,2, etc., and there will be no duplicate encoded symbols sent amongst theencoded symbols sent associated with the two TOIs as long as less than1,000,000 encoded symbols are sent for the file with TOI=1.

The receiver basic UFD method is described with reference to FIG. 11.The receiver can use existing techniques to determine the FEC OTI (F,Al, T, Z, N) in the same format as described above as for the sender, asshown in Step 900 of FIG. 11. For example, the FEC OTI may be embeddedin a FLUTE session description, or the FEC OTI may be encoded into aURL, or the FEC OTI may be obtained via an SDP message (see [RFC 4566]).In Step 910, the receiver sees if more encoded symbols are received, andit may stay at this step until it either receives another encodedsymbol, in which case the receiver proceeds to Step 930, or the receiverdetermines that more encoded symbols are not going to be received, inwhich case the receiver proceeds to Step 920 and either tries to recoverthe file using other means, for example using HTTP requests to a filerepair server, or the receiver may wait for another session to receivemore encoded symbols at a later time, or the receiver may decide thatthe file cannot be recovered.

When another encoded symbol is available, in Step 930 the receiverdetermines the UFSI C of the encoded symbol and receives the value ofthe encoded symbol. In Step 940, the receiver calculates A=C modulo Z,and B=floor(C/Z) based on the number Z of source blocks and the UFSI C,and in Step 950 the receiver sets the (SBN, ESI) for the encoded symbolto (A, B), and in Step 960 the receiver stores the value of the encodedsymbol and (A, B) to be used for file recovery. In Step 970, thereceiver determines if there are enough encoded symbols received torecover the file, and if so proceeds to recover the file in Step 980,and if not proceeds to receive more encoded symbols in Step 910.

There are many variations of the receiver basic UFD method. For example,the receiver can receive more than one encoded symbol in at least someof the packets, in which case the FEC Payload ID may be set to the UFSIof the first encoded symbol contained in the packet and additionalsymbols in the packet may have corresponding UFSI values that areconsecutive. For example, if there are three encoded symbols carried inthe packet and the first such symbol has UFSI=4,234, then the other twoencoded symbols can be those with UFSIs 4,235 and 4,235, respectively,and the UFSI carried in the packet might the UFSI=4,234 of the firstencoded symbol. As examples of other alternatives, the receiver maypredetermine how many encoded symbols to receive before attemptingrecovery. As another example, the receiver may do some processing thatis specific to the FEC code used to determine if enough encoded symbolshave been received to recover the file. As another example, the UFSIvalues may be used directly without an intermediate step of generatingthe (SBN, ESI) values in the recovery process. As another example,recovery of the file may happen concurrently with reception of encodedsymbols. As another example, other forms of FEC OTI information may beused.

Combining the basic UFD method with the techniques described in[IETF-RFC-6330] for determining the source block and sub-block structureprovides many advantages. For example, what previous methods called“source symbols” that were identified by a combination of a SBN and ESIfor purposes of transmitting the file can be viewed as file symbols thatare identified by a UFSI when using the basic UFD method. Let F be thesize of the file in octets to be transmitted, and let T be the symbolsize to be used for FEC encoding/decoding purposes when transmitting thefile, and thus KT=ceil(F/T) is the total number of symbols in the file,where ceil(x) is the smallest integer greater than or equal to x.

When the source block structure and sub-blocking structure is determinedas for example described in [IETF-RFC-6330], and the basic UFD methoddescribed above is used to convert the identification of a symbol from(SBN, ESI) format to and from UFSI format, the range of UFSIs for thefile symbols are 0, 1, 2, . . . , KT, and any repair symbols generatedfrom the file will have UFSIs in the range KT+1, KT+2, etc. Thisproperty allows the determination of whether a symbol is part of theoriginal file or is a repair symbol generated from the file by simplycomparing its UFSI to the value of KT. This can be useful for example toallow receivers that do not support FEC decoding to determine whichsymbols are part of the original file (and their position within thefile) and which can be ignored as repair symbols, based on the UFSIvalue carried in packets, and on the value of KT for the file.

Multiplexed FLUTE

For delivery of data over a network, the data is typically packaged intomessages or protocol data units (“PDUs”), sometimes informally referredto as packets. In some circumstances, it is desirable to multiplex datafor multiple objects or object fragments together within PDUs so as toenable simultaneous receipt. This might be used, for example, whenmixing media streams from distinct origins within a network. Anotherapplication may be multiplexing multiple distinct streams (e.g., audioand video) within the same PDUs for synchronized playback. Anotherapplication is to further enhance the reliability of delivery ofmultiple small objects when the network over which the delivery is madeis not perfect, e.g., there may be losses of packets between the senderand receiver. While it might be possible to carry distinct objects indifferent FLUTE sessions without multiplexing, there is no currentprovision in FLUTE for multiplexing multiple objects or object fragmentsin the same packet.

The FLUTE protocol signaling methods do not fully enable the universalobject delivery methods. For example, the FLUTE protocol is not able tosignal that data for multiple objects are carried within the samepacket. Below we describe additional signaling and delivery methods andapparatus for extending the FLUTE protocol to enable universal objectdelivery. We herein call these extensions “Multiplexed FLUTE”. A basicuniversal file delivery (“UFD”) method and corresponding system(s) willnow be described, wherein the UFD uses universal object delivery (“UOD”)and Template-based file delivery.

UOD can be used to supplement FLUTE with multiplexed object transportencoding. With multiplexed FLUTE, signaling can be used to indicate whenUOD provides FEC encoded data of multiple objects within the same PDUs.Thus, multiplexed FLUTE enhances the current FLUTE protocols to enableencoding multiple objects or object fragments within the same PDUs.

Each FLUTE protocol data unit (“PDU”) carries a Transmission ObjectIdentifier (“TOI”) that indicates for which object the PDU carries data.The directory of objects, used to map TOIs to files and file attributes,is called a File Delivery Table (“FDT”). The structure is shown in FIG.12.

In current FLUTE FDTs, each entry in a FDT is identified by a TOI andcontains information pertaining to one file or object, and thuscorrespondingly each PDU carrying the same TOI carries data for the oneobject associated with the TOI in the FDT. The information may include adescription of the type of FEC scheme used to encode the object and theFEC encoding structure of the object as identified by the FEC ObjectTransmission Information (“OTI”). The FEC scheme is identified by an FECEncoding ID (see [IANA-FEC] for current standard values).

With multiplexed FLUTE, there is a new structure called a PacketStructure Table (“PST”). In this extension to the FLUTE protocol, eachFLUTE PDU carries a Packet Format Identifier (“PFI”) that indicates howeach PDU is structured. In this extension, a PDU may contain data forone or more objects. Each entry in a PST is identified by a PFI andcontains information about the PDU structure of the PDU carrying thatPFI, i.e., the order, size and meaning of the fields in the PDU carryingFEC Payload IDs and associated symbols for objects.

For PDUs carrying a particular PFI, the information associated with thePFI in the PST provides the correspondence between symbols carried insuch PDUs and the corresponding objects from which the symbols weregenerated, the correspondence between FEC Payload IDs carried in suchPDUs and the corresponding symbols that the FEC Payload IDs identify,and the lengths of the FEC Payload IDs carried in such PDUs. The TOIs ofthe objects may be used to help indicate these correspondences in a PSTentry.

An entry identified by a PFI in the PST may be relatively simple or moreinvolved. For example, in a simple case, the entry may describe a PDUformat that contains one FEC Payload ID of a given size, e.g., 2 bytes,and describe one symbol carried in the PDU for one object identified bya particular TOI. In a more involved example, the entry may specify aPDU format that contains multiple FEC Payload IDs of different sizes,e.g., some may be 1 byte, some 2 bytes, some 4 bytes in size, and thesymbols carried in the PDU may be for multiple objects identified in theentry by multiple TOIs, and some FEC Payload IDs may be used foridentifying symbols of more than one object whereas other FEC PayloadIDs may be used for identifying symbols of a single object.

Furthermore, for some objects there may be more than one symbol carriedin the PDU, whereas for other objects there may be only one symbolcarried in the PDU. In other cases, the object identified by a TOI maybe a portion of a content file, e.g., as identified by specifying a URLfor the content file and a byte range in the TOI entry in the FDT.

Template-Based File Delivery

Template-based file delivery, introduced herein, comprises methods bywhich multiple related objects can be named, identified, parameterized,and delivered. Template-based file delivery is facilitated withsignaling and delivery methods that use templates, somewhat akin to how[Luby2010] and [Luby2012] use templates for DASH delivery of streamingcontent. Template-based file delivery provides a compact way ofdelivering the metadata associated with a sequence or set of associatedfiles or objects. The metadata and other properties of the sequence orset of files or objects (or portions of objects) are or can beconstructed to be related in a predictable way so that templates can beused to describe these relationships in a succinct form. Thus,Template-based file delivery can provide an extremely compact andsuccinct means to signal the relationships between the locations, names,availability times, FEC information, and other metadata associated withthe sequence, set, or collection of objects to be delivered, even forobjects in the set of objects that have not yet been created, or are notyet available or known. Template-based file delivery allows the bulk ofthe metadata to be synthesized and delivered in a compact form to adevice to which the sequence of files is to be at least partiallydelivered. Template-based file delivery allows the bulk of the metadatato be delivered to the device or client prior to when the device orclient initiates reception of at least some of the sequence of files.Alternately, the metadata can be delivered to a client or device before,during, or after reception of at least some of the sequence of files.

Template-based file delivery removes the necessity of delivering thebulk of the metadata for files only after the file is created andavailable for delivery, i.e., with Template-based file delivery themetadata can be delivered even before a file is created or is known oravailable at the sender, wherein this metadata can comprise deliverytiming information, handling details as desired, location informationfor the files after they are created on the receiving device, and otherparameters. Template-based file delivery enables the delivery of themetadata for a sequence or collection of associated files to be compactand independent of the delivery of the files themselves, and alsoindependent of the timing of the file delivery and the timing of thecreation or availability of the files for delivery. Since the metadataassociated with files is compact and monolithic when expressed usingtemplates, generally the metadata can be delivered with very highreliability and using different means than is used to deliver files. Forexample, the metadata can be delivered as a small file using HTTP to aclient or device, whereas the files themselves may be delivered over abroadcast or multicast network using FLUTE. The metadata may bedelivered within the eMBMS User Service Description (“USD”) information,or it may be delivered using the Session Description Protocol (“SDP”),or within a conventional file available off the web (e.g., using HTTP).The metadata may be expressed using XML or HTML or any of a variety ofmarkup languages.

With the FLUTE protocol as it exists today, the bulk of the metadata isdelivered using the same delivery method as is used to deliver thefiles. Furthermore, the metadata for a particular file is typicallydelivered at or near the same time as the file is delivered. Also, thereis explicit and particular metadata delivered uniquely for eachparticular file, and the format of the metadata associated with a filedoes not allow the file metadata to be generated and delivered far inadvance of the creation or availability of the file for delivery. If themetadata for a file is not available at the receiver, generally therecovery of the file at the receiver is not possible, even if thereceiver has received enough data in the packets for the file that,together with the metadata for the file, would allow recovery of thefile.

Streaming video or audio is often delivered as a sequence of named filesor fragments. For example, the DASH standard ([3GP-DASH], [MPEG-DASH])specifies such a solution. When delivering streaming multimedia data(video, audio, timed text, etc.) over multicast or broadcast enablednetworks, such as an eMBMS network ([IMBMS]), the FLUTE protocol([FLUTE]) uses a sequence of files that can be delivered as a sequenceof separate objects, sometimes also called segments.

As mentioned above, the FDT in FLUTE contains the names of files butalso important metadata which may be required to successfully collectand decode the file contents. In addition, the FDT may contain the namesof certain files that must be received as a prerequisite for subsequentsuccessful reconstruction of some multimedia stream (e.g., DASHinitialization segments are ordinarily necessary as a prerequisite todecoding and rendering subsequent media samples).

Generally with FLUTE, the name of any particular segment is not known atthe time of transmission of the current segment. Instead, subsequentfile names must be learned by receiving a newer or updated FDT. Thus,both the FDT for the object and the segment itself must be successfullyreceived. If, for example, the receiving client receives a segment butnot the associated FDT object containing the meta-data for the segment,the receiving client will not be able to interpret and deliver thesegment successfully, and thus the segment is effectively lost.

As explained below, the methods described herein can be used to indicatethat particular metadata is common to a sequence of related objects,e.g., a sequence of DASH segments corresponding to a multimedia stream.These methods (“template rules”) provide a succinct description ofmetadata and the objects to which they apply. The receiving client thusneeds only to obtain the template rules in order to obtain all (or most)of the metadata needed for the sequence of related objects, thuseliminating the requirement that the receiving client also receive aseparate FDT for each object to be delivered.

In the more general case, a construction rule is provided that is eithera template rule or some other rule that doesn't specify a template perse.

In the context of eMBMS streaming delivery, the loss of the FDTcontaining the metadata for a segment will generally prevent thereceiving client from understanding the structure of the segment, andthus cause the receiving client to have to discard the entire segment ofvideo and/or audio. The methods and processes described herein thusimprove the quality of experience delivered to end users by reducing thelikelihood a segment will be discarded due to loss of metadata. Anotheraspect is that by substantially reducing the amount of redundantmetadata sent in FDTs with the current FLUTE solution for sequences ofrelated objects, and the corresponding overheads in sending thismetadata, the amount of overall bandwidth used (and latency required)for delivering streams of objects is somewhat reduced using the methodsand processes described herein. One advantage is that the overalldelivery of streams of objects is less complex than required otherwise.

Template FDTs

An FDT carries metadata that relates a file or object identifier for aFLUTE session, expressed as a Transmission Object Identifier (“TOI”), tometadata associated with the file, e.g., a URI for the file, and theForward Error Correction Object Transmission Information (“FEC OTI”)that conveys the associated FEC parameters for delivering the file overFLUTE. A new type of FDT described herein contains template informationdescribing some or all of the FDT metadata needed for a sequence ofrelated objects. This new type FDT, hereafter called a template FDT(“TFDT”), contains metadata information related to a sequence of relatedobjects, including the FEC OTI, but also including other metadatarelated to delivering a sequence of related objects.

As described, the TOI, the FEC OTI and the corresponding URI informationmay be expressed as templates. When used in conjunction with a PST, forexample, the metadata in the PST may also be expressed as templates.

A template is constructed as a baseline constant with zero or morevarying values. Varying values can customize the parameters orcharacters in the URI, FEC OTI, or PST information for specific objects(usually to encode some repeating pattern).

There may be special values with special meaning. For example, as usedabove, the delimiters of “%” may be used to indicate a template (e.g.,within a substring) in which special values are defined. One such value,I, is used to indicate the index (i.e., position in a sequence) of anobject in a sequence of related objects starting within value zero andincrementing by one for each subsequent object, and (as also describedabove) the value of I may be used in templates to, for example, describethe sequence of TOIs for the objects and the sequence of URIs for theobjects, etc.

The sequence of related objects in the TFDT is specified using atemplate that specifies amongst the other possible metadata for thesequence of related objects the range of TOI values to which the TFDTparameter options apply. For example, the TFDT may use a variable I thatindexes from 0 by 1 to the number of objects (which may be unbounded),and then the TOI sequence for the sequence of related objects isspecified using a template that is described using the value of I, e.g.,in the TFDT the TOI template may be expressed as a string like“TOI=%1000+I*3%” that specifies that the sequence of TOIs in thesequence of related objects is 1000, 1003, 1006, 1009, . . . .

The value of I can start at 0, increment by 1, and a maximum value for Ican be specified in the TFDT, e.g., “Maximum I=499”, indicating thatthere are 500 objects in the sequence of related objects. Alternatively,the maximum value of I can be left unspecified, in which case any TOIthat fits into the pattern of TOIs specified by the template would beconsidered to be within the sequence of related objects. The TFDT alsocan include a substring (e.g., HTTP URI prefix) for each object, whichis also specified as a template that is described using the value of I.For example, in the TFDT, the TOI template may include“URI=http://example.com/object%I+300%” that specifies that the sequenceof URIs in the sequence of related objects is as follows:

-   -   http://example.com/object300,    -   http://example.com/object301,    -   http://example.com/object302,    -   http://example.com/object303,

Although this example describes template rules and how they are appliedin the context of FLUTE, this approach is applicable to other filedelivery style protocols that contain file names that are later matchedwith file fragments identified with generic identifiers. Consequentlythis approach is applicable to other delivery systems and applied byusing templates in the metadata description (for example, DASH uses asimilar approach in its Media Presentation Description (“MPD”) templatestructure as described in [Luby2010] and [Luby2012]). Note thatexample.com is not a real domain, per RFC 2606.

The FEC OTI for example for the FEC Encoding Scheme specified in[IETF-RFC-6330] comprises the FEC Encoding ID (6), the file transfersize in bytes (F), the symbol and sub-symbol alignment factor in bytes(Al), the symbol size in bytes (T), the number of source blocks (Z) andthe number of sub-blocks per source block (N). Amongst these particularparameters, only the value of F typically varies from one object to thenext amongst a sequence of related objects, and thus the values of allthe FEC OTI parameters other than the value of F may be specified in theTFDT, e.g., as follows:

-   -   “FEC Encoding ID=6”, “Al=8”, “T=1320”, “Z=1”, “N=1”

In this example, the values in the TFDT for the sequence of relatedobjects specify that they all use the rules and protocols of[IETF-RFC-6330] associated with FEC Encoding ID 6, use the alignmentfactor of 8 bytes, have a symbol size of 1320 bytes, have one sourceblock per object, and have one sub-block per source block. In this case,the varying parameter, i.e., the file transfer size F, may be prependedto the object itself, and the number of source symbols in each objectcan be included as one of the parameters in the FEC Payload ID of eachdata packet or PDU.

For example, the FEC Payload ID format can comprise a two-byteSBN-value, a two-byte ESI-value, and a two-byte KT-value, where theSBN-value indicates from which source block the data carried in the PDUis generated, the ESI-value indicates an encoding symbol ID for the datacarried in the PDU, and the KT-value indicates the total number ofsource symbols comprising the file. An alternate FEC Payload ID formatcan comprise a four-byte UOSI-value and a two-byte KT-value, where theUOSI-value indicates a universal object symbol identifier for the datacarried in the PDU and the KT-value indicates the total number of sourcesymbols comprising the file.

For these two types of FEC Payload IDs, the file or object itself mighthave prepended a four-byte F-value indicating the total number of bytesin the file, where this F-value is prepended before FEC encoding, andthus the source symbols that are to be FEC-encoded for the purpose ofdelivering the file comprise the F-value followed by the actual file. Inthis case, the total number of source symbols KT for the file is equalto ceil((4+F)/T), where T is the symbol size. Alternatively, the filemay have prepended a two-byte P-value indicating the number of paddingbytes in the last source symbol of the file, and in this case the filesize in bytes is F=KT*T−P, where T is the symbol size. In this case, thetotal number of source symbols KT for the file is equal toceil((2+F)/T). In either case, the receiver can process a file asfollows. Each received PDU for the file contains a transport sessionidentifier (“TSI”), a TOI and an FEC Payload ID. From the TSI, TOIcarried in the PDU, and from the TFDT, the receiver can determine all ofthe FEC OTI except for the file or object size F. However, the receivercan determine the number KT of source symbols in the file from the FECPayload ID carried in each PDU (and the receiver can identify whichobject the KT is associated with from the TSI and TOI carried in thePDU). From KT and the other FEC OTI parameters, the receiver candetermine the number of source blocks and the number of source symbolsin each such source block of the file (and the receiver can alsodetermine the number of sub-blocks into which each source block ispartitioned, and the size of the sub-symbol for each sub-block). Once atleast enough symbols have been received for each source block, which istypically when KT or slightly more than KT symbols in total have beenreceived for the file, the receiver can FEC-decode and recover the KTsource symbols of the file. Once the KT source symbols for the file havebeen recovered, the receiver can determine from the value of F, or P,prepended to the source symbols, the F-bytes of the source symbolscomprising the file.

As another alternative, the four-byte F-value may be appended to thefile or object instead of prepended, where the F-value is appendedbefore FEC encoding, and thus the source symbols that are to beFEC-encoded for the purpose of delivering the file comprise the actualfile followed by possible padding followed by the F-value as the lastfour bytes of the last source symbol of the file, where the total numberof source symbols KT for the file is ceil((4+F)/T). Once the receiverhas recovered the KT source symbols of the file, the receiver determinesthe number of bytes F comprising the file from the last four bytes ofthe last recovered source symbol, and then the file itself comprise thefirst F-bytes of the recovered source symbols. Another alternative iswhere the P-value is appended to the file instead of the F-file, withsimilar procedures on how the source symbols are formed and how thereceiver recovers the file.

As another alternative, the FEC Payload ID can comprise a two-byteSBN-value, a two-byte ESI-value, and a four-byte F-value. In thisalternative, the source symbols can comprise the file itself with novalues prepended or appended, as the receiver can recover the size ofthe file in bytes directly from the FEC Payload ID. As anotheralternative, the FEC Payload ID can comprise a four-byte UOSI-value, andthe F-value can be carried in an extension header, for example theEXT_FTI extension header with extension header identifier 64 asspecified in [LCT].

With the methods described herein using the TFDT, there is no need for aseparate FDT for each object, as all of the common information for thesequence of related objects is carried in the TFDT, and the informationthat is specific to each object is (in this example) partially carriedin the FEC Payload ID of the packets carrying data for the object (thenumber of source symbols in the object) and partially carried in thesource symbols of the object, i.e., prepended or appended to the sourcesymbols of the object before FEC encoding (the size of the file F inbytes, or equivalently the number P of bytes in the last source symbolof the object to be discarded).

For example, an FEC OTI for RaptorQ (see, e.g., [IETF-RFC-6330]; FECEncoding ID 6) might have as structure such as is shown in Table 1.

TABLE 1 Category Details Example Value Mandatory FEC FEC Encoding ID  8bits (value 6) OTI value Common FEC F (transfer length 40 bits (transferlength of object) OTI value [source]) with limit of 946270874880 T(symbol size) 16 bits (size of a symbol in bytes) Scheme specific Z (#of source  8 bits OTI values blocks) N (# of 16 bits sub-blocks) A1(alignment)  8 bits

It is expected that for a session of multiple objects, these FEC OTIvalues would all remain constant except for the F value. If a PST werealso used (e.g., to encode multiple objects together in a PDU), and theprotocol allowed for variable-sized TOIs or FEC Payload IDs, it istypical that the size of each TOI and FEC Payload ID and the size of thesymbols for each constituent object present in each PDU (expressed inbytes) remains unchanged for the sequence of related objects.

For example, a PST for the objects might specify two objects per PDU,with a 2-byte FEC Payload ID for each object (each object uses aseparate FEC Payload ID in this example, in other cases the two objectsmight share the same FEC Payload ID). With this solution, the PFI isincluded in each PDU to indicate which packet format structure the PDUsfollow.

With a TFDT as described herein, the PST and the FDT might be combinedinto a TFDT that might look as shown in Table 2.

TABLE 2 PFI = %I% “Number of objects = 2”, “First object FEC Payload IDsize = 2 bytes” “Second object FEC Payload ID size = 2 bytes” “Firstobject = 1 symbol per PDU” “Second object = 1 symbol per PDU” “Firstobject URI = http://example.com/video%I%” “First object FEC OTI = (6, 8,664, 1, 1)” “Second object URI = http://example.com/audio%I%” “Secondobject FEC OTI = (6, 8, 664, 1, 1)”

Thus, in this example, the PDUs will use the PFI sequence 0, 1, 2, 3, .. . for the sequence of related objects, and the PDUs containing PFIvalue 50 will contain one symbol of 664 bytes for each of two objects,wherein the URI for the first object is http://example.com/video50 andthe URI for the second object is http://example.com/audio50, and the twoobjects both have one source block and one sub-block per source block,and both use FEC Encoding ID 6 and use alignment factor 8 bytes.

Below is an example of a TFDT where in this case there is one sessionwith metadata provided for two sequences of related objects. In thisexample, the first sequence of files may for example correspond to asequence of video segments from a DASH video representation, and thesecond sequence of objects corresponds to a sequence of DASH audiosegments from a DASH audio representation. In this example, the standardFEC Payload ID specified in [IETF-RFC-6330] is used, i.e., each datapacket contains one symbol for one object, and the FEC Payload IDcomprises an 8-bit SBN and a 24-bit ESI. In this example, “%” serves asa delimiter for variables and equations.

     // TFDT with metadata for two sequences of files specified      //All sequences of files in this TFDT have the same transport sessionidentifier      TSI = 5      // All sequences of files in this TFDT usethe same time scale      Timescale = 10      MPD_URL =http://news.video_content/sept25.2012.mpd      // First sequence ofobjects metadata      <start_seq_template_specification>         Counter%I = 0..99999%         TOI = %2000000+I%         URI =http://localhost.seq1/object%I%         MPD_REP_ID =http://newsfeed.example.com/         video500         START_TRANSMISSION= %I*20%         END_TRANSMISSION = %I*20 + 20%         FEC_OTI = (6, 8,1288, 1, 1)      <end_seq_template_specification>    // Second sequenceof objects metadata      <start_seq_template_specification>        Counter %I = 0..49999%         TOI = %3000000+I%         URI =http://localhost.seq2/object%I%         MPD_REP_ID =http://newsfeed.example.com/         audio64         START_TRANSMISSION= %I*40%         END_TRANSMISSION = %I*40 + 80%         FEC_OTI = (6, 4,540, 1, 1)      <end_seq_template_specification>

In this example TFDT above, these sequences of objects or filescorrespond to representations described in a DASH MPD, i.e., the MPD atthe URL http://newsfeed.video_content/sept25.2012.mpd provided afterMPD_URL. The MPD_REP_ID specified for a sequence of files in the aboveTFDT provides an identifier for the corresponding representation in theMPD. In the example above, the MPD_REP_ID is the base URI or URLprovided within the MPD for that representation, which uniquelyidentifies the representation amongst all the representations describedwithin the MPD. This signaling provides a method for linking thedelivery information associated with a sequence of objects or filessignaled in a TFDT with the DASH metadata information associated withrepresentations signaled in a MPD.

In the first sequence of files, the FEC OTI specifies that the FEC codewith FEC Encoding ID=6 is used, which is the RaptorQ code specified in[IETF-RFC-6330], and that an alignment factor of 8 is to be used, andthat each symbol is 1288 bytes in size, and that each object or file isFEC encoded as one source block with one sub-block per source block. Forthe second sequence of files, the FEC OTI specifies that the FEC codewith FEC Encoding ID=6 is used, which is the RaptorQ code specified in[IETF-RFC-6330], and that an alignment factor of 4 is to be used, andthat each symbol is 540 bytes in size, and that each object or file isFEC encoded as one source block with one sub-block per source block.

The value of Timescale provides a reference for time measurements inunits of ticks per second. All units of time are expressed in units ofticks per second using Timescale, e.g., in the example aboveTimescale=10, and thus a time duration of 55 indicates a 55 tickduration, which corresponds to a 5.5 second duration. TheSTART_TRANSMISSION and END_TRANSMISSION provided for each sequence offiles in the TFDT above can be used to indicate the start transmissiontime of each file and the end transmission time of each file using atemplate. Thus, data packets for the file corresponding to I within thefirst sequence of files is to be transmitted between times I*20 andI*20+20 relative to the beginning transmission time of the session. Inthis example, because Timescale=10, this means that data packets foreach file are transmitted for 2 seconds, and the data packets for thefile corresponding to I are transmitted starting at 2*I seconds afterthe beginning transmission time of the session, and thus there is nooverlap in transmission time for packets of consecutive files from thefirst sequence of files. Similarly, data packets for the filecorresponding to I within the second sequence of files is to betransmitted between times I*40 and I*40+80 relative to the beginningtransmission time of the session. In this example, because Timescale=10,this means that data packets for each file are transmitted for 8seconds, and the data packets for the file corresponding to I aretransmitted starting at 4*I seconds after the beginning transmissiontime of the session, and thus there is a 4 second overlap intransmission time for packets of consecutive files from the secondsequence of files. The receiver can use this information to determinethe time interval for when data packets for a file from a sequence offiles are expected to arrive. There are many variants of the signalingof the start and end transmission time of files using templates. Forexample, more than one start and end transmission time might beindicated using a template for a sequence of files, e.g., two start andend transmission times might be indicated in the TFDT using templates toindicate a time shift broadcast of the same DASH stream of videocontent.

Since the TOIs are scoped by the TSI in a FLUTE session, in order for areceiver to be able to determine which received packets should beassociated with which file, the TOI should be distinct for all files orobjects delivered with the same TSI value. Thus, if two sequences offiles are to be transmitted within the same session, it is preferablethat their corresponding ranges of TOI values have an emptyintersection, i.e., there are no duplicate TOI values. There are manyways to achieve this. For example, one method is to use sequential TOIvalues for each file sequence, but ensure that the starting TOI valuefor a first file sequence and the starting TOI value for a second filesequence with the next larger starting TOI value are separated by atleast the maximum number of TOI values to be used for the first filesequence. This is the method used in the TFDT example above: the firstsequence of files has a start TOI value of 2,000,000 and uses at most100,000 consecutive TOI values, i.e., TOIs in the range 2,000,000through 2,099,999, whereas the second sequence of files has a start TOIvalue of 3,000,000. Thus, there are 1,000,000 TOI values between thestart TOI values of the first and second file sequence, but only 100,000of these TOI values are used by the first file sequence, so there are noduplicate TOI values used by the two file sequences.

Another method to achieve no duplicate TOI values used by differentsequences of files is to place an upper bound on the number of sequencesof files that can be delivered within a single session. For example, ifthere is a limit of at most 256 sequences of files within a session,then the J-th such sequence of files can have a TOI sequence specifiedas:

TOI=% J+256*I %

Then, each TOI for a file within the J-th sequence of files will have aTOI that is equal to J modulo 256, and thus the TOIs for each of thesesequences of files will be distinct at long as each sequence of filesuses a different J value modulo 256 to define its sequence of TOIs.

The above methods ensure that all TOIs used by any of the files in anyof the sequences of files delivered within a session are distinct, butthis requirement can be relaxed. For example, it is sufficient if thereceiver can determine at the time that a packet is received which ofthe files it is to be associated. The start and end transmission timesof each file within a sequence of files can also be used by the receiverto distinguish between different TOI sequences. Suppose in the exampleabove that the TOI sequence for the second sequence of files was changedto

TOI=%1999990+I %

In this case, the TOIs for the first sequence of files and for thesecond sequence of files would be overlapping, i.e., the TOI range forthe first sequence of files is 2000000-2099999 and the TOI range for thesecond sequence of files is 1999990-2049989. However, a receiver thattracks time relative to the beginning of a session transmission candetermine to which file a received data packet should be associated. Forexample, if T seconds have elapsed since the beginning of the session,then the possible TOI for a data packet associated with a file from thefirst sequence of files is 2000000+floor(T/2) and the possible two TOIsfor a data packet associated with a file from the second sequence offiles are 1999990+floor(T/4) and 1999990+floor(T/4)−1. It can beverified in this example that these three TOIs are always distinct, andthus the receiver can determine for a received data packet whichsequence of files and which file within that sequence to associate withthat data packet based on the received TOI within the data packet andthe elapsed time T.

In general, there may be some variations in the actual send timeinterval for data packets of a file, and also some variance in thedelivery time of data packets from a sender to a receiver, and the timeof a sender and a receiver might not be completely synchronized, andthus the above methods for distinguishing and determining which file isassociated with a received data packet should take into accounttolerances between signaled times and actual receive times of datapackets. The methods described herein for determining which sequence offiles and which file within the sequence to associate a received datapacket based on the TOI, and possibly TSI, within the packet and on theelapsed time T, should take into account these tolerances. For example,it might be the case that from a system perspective a tolerance of tenseconds is reasonable, and thus the signaling within the TFDT shouldhave the property that for any first file from a first sequence of filesand any second file from a second sequence of files, if the signaled TOIfor the first file and the second file are the same then the signaledstart transmission time for the second file should be at least tenseconds after the signaled start transmission time of the first file, orthe signaled end transmission time for the second file should be atleast ten seconds prior to the signaled start transmission of the firstfile.

The TOIs for all objects with overlapping transmission times might beunique, with the TOI, the start transmission time, and the endtransmission time of each object in the sequence of objects describedwithin the template file delivery table by a construction rule.

A client running on an end user device, often called user equipment (or“UE, in the context of 3GPP), needs to differentiate uniquely which datapackets are associated with which file it is trying to recover. The TOIprovides this mapping. However, in some instances, it might be hard tohave unique TOIs. For example, the TOI space of names is only so large,and streaming file delivery might exceed that space, especially if thereare multiple streams scoped by the same TSI (transmission session ID,which scopes the TOI=transmission object ID).

In some embodiments, uniqueness is a requirement, but in otherembodiments, there are various ways to ensure that the client/UEuniquely associates data packets with the correct file. For example,each file sent within a session can be sent with the same TSI and allunique TOIs. Another example is for the transmitter to ensure that allfiles sent within a session are sent with the same TSI over a movingperiod of time (with guard time intervals on either end in case theclient/UE is not completely time synchronized with the transmission) allhaving unique TOIs, and that the client is at least somewhatsynchronized with the transmission so that the client/UE can uniquelydetermine which data packets are associated with each file by using acombination of the TOI in the data packets and the time at which thedata packets are received. In that case, the client would, based on thetime a data packet is received, determine which files are actively beingsent at that time, for example based on start and end transmission timesfor each file, with a guard time interval around these times to extendout the time on each side of these start and end transmission times incase the client clock is not completely synchronized with the actualtimes of transmission/reception of data packets for file. Thus, all ofthese files within this guard time interval will be associated withunique TOIs.

The set of such TOIs of all files transmitted at or within a certaintime period of the arrival of a given data packet might be the set S,and the client can determine which file is associated with each TOI inS. Then, the client can match the TOI in the received data packet withone of the TOIs in S, and thereby determine from which file the data inthe received data packet was generated.

One advantage of these methods is that they can greatly enhancereliability and simplicity when delivering multimedia streams e.g., ascurrently contemplated for delivering DASH formatted streams over eMBMS.Reliability is enhanced because instead of having to deliver a separateFDT for each file at or near the time the data packets for the file aresent, a single TFDT that compactly describes the FDTs for all the filescan delivered reliably prior to the delivery of the individual files.Efficiency is enhanced because a smaller number of bytes are required torepresent the same amount of information when this particular encodingis used.

There are many variants of the TFDT methods described above. Forexample, the format of the TFDT may be similar to that of an FDT anddelivered in a similar manner, i.e., delivered within the transmission(e.g., FLUTE) session as a separate object with TOI=0. Alternatively, aTFDT may be delivered via as an XML object, associated with a URL, and areceiver may download the XML object referenced by the URL using HTTP.Other methods for formatting and delivering TFDT information toreceivers include including the TFDT information in the User ServiceDescription (“USD”) that is used in MBMS to deliver FLUTE metadata toreceivers. Other methods include delivering the TFDT information via aSession Announcement Protocol (“SAP”) message, and to format the TFDTinformation using a Session Description Protocol (“SDP”). Otheralternatives include formatting and delivering TFDT information in aRich Site Summary or Really Simple Syndication (“RSS”) feed. The TFDTinformation may be formatted and delivered using combinations ofmethods, e.g., partially delivered via the USD, partially delivered aspart of a DASH MPD. In some cases at least some portions of the TFDTinformation may be formatted and delivered redundantly, i.e., someportions of the TFDT information may be formatted and delivered usingone method and the same portions of the TFDT information may beformatted and delivered using a different method.

Traditional delivery of individual files and the delivery of sequencesof related files or objects may all be delivered within the same filedelivery session. The signaling for the sequences of related files mayuse the TFDT methods described herein, wherein the individual filesdelivered with the same session may be delivered using traditional FDTs.In any case, it is preferable if the metadata for the sequences ofrelated files and for the individual files delivered within the samesession make it possible for the receiver to operate correctly, e.g.,the TOI for an individual file should not match the TOI of any file forany sequence of files for which data packets are transmitted at the sametime as data packets for the individual file. Alternatively, themetadata for the individual files may also be included in the TFDT, andthus the TFDT information comprises the delivery metadata for theindividual files as well as for the sequences of related files for asession. As another alternative, a TFDT may contain all or portions ofthe metadata for files delivered in multiple transport sessions. Asanother alternative, a TFDT or multiple TFDTs may contain metadata forfiles for which packets are transmitted into multiple delivery sessions.

Another UOD Example

Template-based file delivery and UOD address complementary important usecases for joint protection of multiple objects and can be usedseparately or together.

The FEC OTI for Basic UOD RaptorQ can be exactly the same as for RaptorQin [IETF-RFC-6330], but the FEC Payload ID can be simplified. The FECPayload ID for RaptorQ in [IETF-RFC-6330] is (SBN, ESI), while the FECPayload ID for Basic UOD RaptorQ is UOSI. Transmitting symbols in UOSIsequence utilizes network resources in an efficient and flexiblefashion.

An example of mapping an (SBN, ESI) pair to a UOSI can be as follows. Todetermine a (SBN, ESI) pair from a UOSI value, C, for an object known tohave Z source blocks, set ESI=floor(C/Z) and then set SBN=C−(ESI)*Z. Todetermine a UOSI value, C, from a (SBN, ESI) pair for an object known tohave Z source blocks, set C=SBN+(ESI)*Z. Table 3 shows an examplemapping for Z=5.

TABLE 3 UOSI (C) SBN ESI 0 0 0 1 1 0 2 2 0 3 3 0 4 4 0 5 0 1 6 1 1

FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI).

FIG. 14 illustrates an example object with FEC Payload ID (UOSI).

In a PST, each entry is identified by a unique PFI. Each entry in thePST contains (1) The number and sizes of FEC Payload IDs in a packet,(2) a specification of which object is associated with each symbol in apacket (it can use TOIs to make this association), and (3) aspecification of which FEC Payload ID to use for each symbol in apacket. The PFI is carried in each packet to identify the format anddata that is carried in the packet.

For example, a first PST entry might specify a packet format comprisingtwo FEC Payload IDs of two bytes each—UOSI format, with one symbol forthe first object with TOI that uses the first FEC Payload ID, and onesymbol for the second object with TOI that uses the second FEC PayloadID.

In general, the PH could carry a list of sizes and formats of FECPayload Ids, and the number of symbols of each of the objects carried inthe packet, and the tie in to the FEC OTI. The PFI could also be carriedin the FDT and associated with a TOI. As an example of a PFI, the PFIcould indicate that the packets associated with a TOI carries 3 objects,with associated URLs and FEC OTI, and the format of the packets are: thefirst object has a UOSI of 1 byte and one symbol in the packet, thesecond object shares the UOSI with the first object and uses two symbolsin the packet, the third object has a UOSI of 2 bytes and one symbol inthe packet, and in this case the packet would contain a 1 byte UOSI forthe first object, this UOSI would also be used for the second object,then a 2 byte UOSI for the third object, then one symbol for the firstobject, 2 symbols for the second object, and one symbol for the thirdobject.

As has now been described, there are some specific examples. Furtherembodiments can be envisioned to one of ordinary skill in the art afterreading this disclosure. In other embodiments, combinations orsub-combinations of the above-disclosed invention can be advantageouslymade.

Recovery at a decoder can be an exact recovery or at least approximatelyrecovery of what was transmitted. Even if some data packets are lost,some can still be associated with their original data packet usingtransmission object identifiers. These transmission object identifiersmight be constructed by a transmission object identifier constructor.For example, if two transmission object identifiers, they may be deemedto be associated with the same encoded symbols. Data can be arranged asone or more sequences of data objects. The sender and/or receiver can bean electronic device or system that communicates over a packet switchednetwork. Packets can be generated from the sequences of data objectsusing a packet constructor to provide a packet output. Meta-data is anexample of data in structured form, as might be useful for automatedprocessing. The meta-data might be generated using templates and/or atemplate file delivery table.

The example arrangements of components are shown for purposes ofillustration and it should be understood that combinations, additions,re-arrangements, and the like are contemplated in alternativeembodiments of the present invention. Thus, while the invention has beendescribed with respect to exemplary embodiments, one skilled in the artwill recognize that numerous modifications are possible. For example,the processes described herein may be implemented using hardwarecomponents, software components, and/or any combination thereof. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims and that the invention is intended to cover allmodifications and equivalents within the scope of the following claims.

What is claimed is:
 1. A method of delivering one or more data objectsfrom an electronic device or system over a packet-switched network,wherein source data of the one or more data objects is represented byencoded symbols in packets such that the source data is recoverable, atleast approximately, from the encoded symbols, the method comprising: a)generating data in a structured form, including meta-data; and b)generating meta-data using templates for delivering sequences of relatedobjects.
 2. A method of delivering one or more data objects from anelectronic device or system over a packet-switched network, whereinsource data of the one or more data objects is represented by encodedsymbols in packets such that the source data is recoverable, at leastapproximately, from the encoded symbols, the method comprising: a)generating data in a structured form, including meta-data; and b)generating meta-data using multiplexed object transport encoding.
 3. Amethod of delivering a sequence of data objects from an electronicdevice or system over a network to a client device, wherein source dataof the sequence of data objects is represented by encoded symbols inpackets such that the source data is recoverable, at leastapproximately, from the encoded symbols, the method comprising:obtaining a template file delivery table that comprises deliverymetadata for the sequence of data objects, the sequence of data objectscomprising a plurality of data objects; constructing a firsttransmission object identifier for a data object from the sequence ofdata objects based on a transmission object identifier construction ruledescribed in the template file delivery table for the sequence of dataobjects; receiving one or more data packets; extracting a secondtransmission object identifier from a received data packet; associatingencoded symbols comprising the received data packet with the data objectif the first transmission object identifier and the second transmissionobject identifier identify the same data object; and recovering, atleast approximately, the source data for the data object based on theencoded symbols associated with the data object.
 4. The method of claim3, wherein a start transmission time and end transmission time for thedata object are constructed based on a start transmission timeconstruction rule and an end transmission time construction rule for thesequence of data objects described in the template file delivery table,and wherein the client device receives data packets for the data objectat times that are between the start transmission time and endtransmission time.
 5. The method of claim 3, wherein more than one dataobject is recovered from the sequence of data objects.
 6. The method ofclaim 3, wherein more than one sequence of data objects is describedwithin the same session in the template file delivery table.
 7. Themethod of claim 3, wherein the template file delivery table alsocomprises information that relates how the sequence of data objects areassociated with segments of a representation describe in a DASH MPD. 8.The method of claim 3, wherein the template file delivery table alsocomprises the FEC object transmission information that is common to allobjects in the sequence of data objects.
 9. The method of claim 3,wherein the template file delivery table comprises metadata deliveryinformation for objects within the sequence of data objects that do notexist at the time that the template file delivery table is obtained bythe client device.
 10. The method of claim 3, wherein the transmissionobject identifiers described within the template file delivery table forall objects are unique.
 11. The method of claim 10, wherein there are atleast two sequences of objects described within the same deliverysession within the template file delivery table and the transmissionobject identifiers for all objects are unique.
 12. The method of claim3, wherein the transmission object identifiers for all objects withoverlapping transmission times are unique, wherein the transmissionobject identifier and the start transmission time and end transmissiontime of each object in the sequence of data objects is described withinthe template file delivery table by a construction rule.
 13. The methodof claim 12, wherein there are at least two sequences of objectsdescribed within the same delivery session within the template filedelivery table and the transmission object identifiers for all objectswith overlapping transmission times are unique.
 14. A method ofdelivering a sequence of data objects from an electronic device orsystem over a network to a client device, wherein source data of thesequence of data objects is represented by encoded symbols in packetssuch that the source data is recoverable, at least approximately, fromthe encoded symbols, the method comprising: obtaining a template filedelivery table that comprises delivery metadata for the sequence of dataobjects, the sequence of data objects comprising a plurality of dataobjects; receiving one or more data packets; extracting a transmissionobject identifier from a received data packet; associating encodedsymbols comprising the received data packet with a data object from thesequence of data objects that corresponds to the transmission objectidentifier as determined by the transmission object identifierconstruction rule for the sequence of data objects described in thetemplate file delivery table; and recovering, at least approximately,the source data for the data object based on the encoded symbolsassociated with the data object.
 15. The method of claim 14, wherein astart transmission time and end transmission time for the data objectare constructed based on a start transmission time construction rule andan end transmission time construction rule for the sequence of dataobjects described in the template file delivery table, and wherein theclient device receives data packets for the data object at times thatare between the start transmission time and end transmission time. 16.The method of claim 14, wherein more than one data object is recoveredfrom the sequence of data objects.
 17. The method of claim 14, whereinmore than one sequence of data objects is described within the samesession in the template file delivery table.
 18. The method of claim 14,wherein the template file delivery table also comprises information thatrelates how the sequence of data objects are associated with segments ofa representation describe in a DASH MPD.
 19. The method of claim 14,wherein the template file delivery table also comprises FEC objecttransmission information that is common to all objects in the sequenceof data objects.
 20. The method of claim 14, wherein the template filedelivery table comprises metadata delivery information for objectswithin the sequence of data objects that do not exist at the time thatthe template file delivery table is obtained by the client device. 21.The method of claim 14, wherein the transmission object identifiersdescribed within the template file delivery table for all objects areunique.
 22. The method of claim 21, wherein there are at least twosequences of objects described within the same delivery session withinthe template file delivery table and the transmission object identifiersfor all objects are unique.
 23. The method of claim 14, wherein thetransmission object identifiers for all objects with overlappingtransmission times are unique, wherein the transmission objectidentifier and the start transmission time and end transmission time ofeach object in the sequence of data objects is described within thetemplate file delivery table by a construction rule.
 24. The method ofclaim 23, wherein there are at least two sequences of objects describedwithin the same delivery session within the template file delivery tableand the transmission object identifiers for all objects with overlappingtransmission times are unique.
 25. An object delivery server fordelivering a sequence of data objects over a network to one or moreclient device, wherein source data of the sequence of data objects isrepresented by encoded symbols in packets such that the source data isrecoverable, at least approximately, from the encoded symbols, theobject delivery server comprising: storage for a template file deliverytable representing delivery metadata for the sequence of data objects,the sequence of data objects comprising a plurality of data objects; apacket constructor that constructs a first transmission objectidentifier for a data object from the sequence of data objects based ona transmission object identifier construction rule described in thetemplate file delivery table for the sequence of data objects and asecond transmission object identifier for a different data object fromthe sequence of data objects based on a transmission object identifierconstruction rule described in the template file delivery table for thesequence of data objects; and a packet output that outputs one or moredata packets as constructed by the packet constructor for the dataobject and the different data object, wherein data objects are encodedwith transmission object identifiers
 26. The object delivery server ofclaim 25, the data objects further comprising a start transmission timeand end transmission time for the data object constructed based on astart transmission time construction rule and an end transmission timeconstruction rule for the sequence of data objects described in thetemplate file delivery table, such that the one or more client devicereceives data packets for the data object at times that are between thestart transmission time and end transmission time.
 27. The objectdelivery server of claim 25, wherein more than one sequence of dataobjects is described within the same session in the template filedelivery table.
 28. The object delivery server of claim 25, wherein thetemplate file delivery table also comprises information that relates howthe sequence of data objects are associated with segments of arepresentation describe in a DASH MPD.
 29. The object delivery server ofclaim 25, wherein the template file delivery table also comprises FECobject transmission information that is common to all objects in thesequence of data objects.
 30. The object delivery server of claim 25,wherein the transmission object identifiers described within thetemplate file delivery table for all objects are unique.
 31. The objectdelivery server of claim 30, wherein there are at least two sequences ofobjects described within the same delivery session within the templatefile delivery table and the transmission object identifiers for allobjects are unique.
 32. The object delivery server of claim 25, whereinthe transmission object identifiers for all objects with overlappingtransmission times are unique, wherein the transmission objectidentifier and the start transmission time and end transmission time ofeach object in the sequence of data objects is described within thetemplate file delivery table by a construction rule.
 33. The objectdelivery server of claim 32, wherein there are at least two sequences ofobjects described within the same delivery session within the templatefile delivery table and the transmission object identifiers for allobjects with overlapping transmission times are unique.